Skip to content

chore: Improve type hints for async bound_params, auth_token_getters, and client_headers #249

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 1 commit into from
May 20, 2025
Merged

chore: Improve type hints for async bound_params, auth_token_getters, and client_headers #249

merged 1 commit into from
May 20, 2025

Conversation

anubhav756
Copy link
Contributor

@anubhav756 anubhav756 commented May 20, 2025 •
edited
Loading

This PR enhances the type hints for bound_params, auth_token_getters, and client_headers arguments in the APIs of both tool and client classes.

Previously, these type hints incorrectly suggested that these callables could only be synchronous functions, or in some cases, specifically Coroutine objects:

  • auth_token_getters: Expected Callable[[], str]
  • bound_params: Expected Callable[[], Any]
  • client_headers: Coroutine

This was inaccurate as these can also be asynchronous (async def) functions.

This PR corrects the type hints to accurately reflect that these callables can be either synchronous or asynchronous:

  • auth_token_getter: Now accepts Callable[[], str] or Callable[[], Awaitable[str]].
  • bound_params: Now accepts Callable[[], Any] or Callable[[], Awaitable[Any]].
  • client_headers: Now accepts Callable[[], Any] or Callable[[], Awaitable[str]].

This ensures type checkers correctly validate both synchronous and asynchronous implementations for these parameters.

This PR also improves accuracy for auth_token_getter signatures to be more abstract parameter types:
* Previously: For auth_token_getter callables that accepted dict arguments in their own signature.
* Now: These have been updated to use typing.Mapping. This is more accurate as it allows for any object implementing the mapping protocol (not just dict instances), offering greater flexibility.

@anubhav756 anubhav756 self-assigned this May 20, 2025
@anubhav756 anubhav756 requested a review from a team as a code owner May 20, 2025 08:30
@anubhav756 anubhav756 changed the title chore: Make type hints of tool and client classes more accurate and specific chore: Improve type hints for async bound_params and auth_token_getters May 20, 2025
@anubhav756 anubhav756 changed the title chore: Improve type hints for async bound_params and auth_token_getters chore: Improve type hints for async bound_params, auth_token_getters, and client_headers May 20, 2025
@twishabansal
Copy link
Contributor

Why are we using callables that take no args?

I believe Callable[[], str] represents a callable that takes in no args and returns a string.

twishabansal
twishabansal reviewed May 20, 2025
View reviewed changes
@anubhav756
Copy link
Contributor Author

Why are we using callables that take no args?

I believe Callable[[], str] represents a callable that takes in no args and returns a string.

We expect the user to pass in functions that produce values without depending on anything from inside the tool or client.

Does that make sense?

@anubhav756 anubhav756 requested a review from twishabansal May 20, 2025 11:45
@twishabansal
Copy link
Contributor

Why are we using callables that take no args?
I believe Callable[[], str] represents a callable that takes in no args and returns a string.

We expect the user to pass in functions that produce values without depending on anything from inside the tool or client.

Does that make sense?

I was wondering why not allow users to bind params based on anything from tool or client or even just env variables.

@anubhav756
Copy link
Contributor Author

anubhav756 commented May 20, 2025 •
edited
Loading

Why are we using callables that take no args?
I believe Callable[[], str] represents a callable that takes in no args and returns a string.

We expect the user to pass in functions that produce values without depending on anything from inside the tool or client.
Does that make sense?

I was wondering why not allow users to bind params based on anything from tool or client or even just env variables.

Could you provide some use cases if possible?

Thinking about this a bit more, I see one use case where users might want to pass in tool's name, for instance, as one of the bound param values. Just thinking if something like that might sound like a future PR?

@anubhav756 anubhav756 merged commit 996545e into main May 20, 2025
19 checks passed
@anubhav756 anubhav756 deleted the anubhav-types branch May 20, 2025 18:02
@release-please release-please bot mentioned this pull request May 20, 2025
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@kurtisvg kurtisvg kurtisvg approved these changes

@twishabansal twishabansal Awaiting requested review from twishabansal

Assignees

@anubhav756 anubhav756

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@anubhav756 @twishabansal @kurtisvg